CONFIGURABLE SOFTWARE SYSTEM AND USER INTERFACE 



FOR AUTOMATICALLY STORING COMPUTER FILES 



Field of the Invention 

This invention relates to a software application and conq)uter interface for 
indexing and storing computer data files. 

Background of the Invention 
When storing an electronic document, a con5)uter user typically stipulates the file 
name and location where the file is to be stored. The file can be retrieved at a later time 
either by recalling the location where the file has been stored, or if the location has been 
forgotten, by searching through folders, sub-folders, and files to identify the desired file. 
This is a user-driven task, and retrieving files is often dependent on how adept the user is 
at remembering file names and locations. Finding a file when the location has been 
forgotten is often a time consuming task. This problem is increasing as the number and 
size of computer files increases. Many computer systems provide the user with a search 
capability that enables the user to search for files under a number of criteria. Common 
search criteria include file name, file type, date created or modified, and file content. 
The number of search criteria defines the flexibility or options a user has in searching for 
files. Having more criteria increases a user's ability to find files, enabling a better, more 
precise and efficient search. 

Summary of the Invention 
One embodiment of the invention is directed to a process for associating 
scheduling data with a file consisting of the following acts: (A) stipulating a schedule of 
events with dates, times and activities; (B) using a computer, for example to create, 
modify, delete or access a current file; (C) comparing at least one characteristic of tiie 
current file against tiie schedule; (D) associating a searchable label to tiie current file 
when the current file matches at least one characteristic of the schedule; and (E) 
retrieving the current file using the label. 
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Brief Description of the Drawings 

Fig. 1 illustrates a flow diagram of steps to cany out the filing and mdexing 
process, according to one embodiment of the invention; 

Fig. 2 illustrates a sample user interface to an application that could be used to 
build a schedule of activities, dates, and times; 

Fig. 3 illustrates a representation of sample data associated with a schedule of 
classes, for example, for a student; 

Fig. 4 illustrates a representation of sample data associated with a schedule of 
meetings, for exan^le, for a businessperson; 

Fig. 5 illustrates a representation of the process by which relevant information is 
accessed about a new document, according to one embodiment of the invention; 

Fig. 6 illustrates an overview of the process for matching schedule attributes to a 
file, according to one embodiment of the invention; 

Fig. 7 illustrates an overview of the process associated with a positive match 
between file and schedule, according to one embodiment of the invention; 

Fig. 8 illustrates a database structure where attributes associated witti files arc 

stored; 

Fig. 9 illustrates an overview of the process associated with a negative match 
between file and schedule, according to one embodiment of the invention; 

Fig. 10 illustrates a user interface wifli which the user can search for files with 
specified attributes; 

Fig. 1 1 illustrates a flow diagram of steps to carry out the filing and indexing 
process, according to another embodiment of the invention; 

Fig, 1 2 illustrates a sample folder structure created tiirough steps ouflined in ttie 
process of Fig. 11; 

Fig. 13 illustrates tiie results of identifying a positive match between file and 
schedule, according to tiie process of Fig. 1 1 ; and 

Fig. 14 illustrates an overview of a process associated witii a negative match 
between file and schedule, according to another embodiment of the invention; 

Fig. 15 illustrates a user interface for saving and editing attributes to a file; 

Fig. 16 illustrates a second embodiment of the user interfaces for savings and 
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editing attributes to a file. 



Detailed Description 

In accordance with one embodiment of the present invention, a configurable 
software system is provided for automatically assigning attributes to conq>uter files. 
These attributes are stored and can be searched by a user to identify files. These 
attributes provide additional search criteria to the user, increasing search flexibility and 
enabling a better, more precise and efficient search. 

A first iDustrative example of the configurable software system is described 
making reference to Figs, 1-10. To begin, in Fig. 1, a user inputs (in act 11) a schedule 
into the computer system by using a user interface. A sample user interface is given in 
Fig. 2, although numerous other arrangements are possible. A user interface for entering 
a schedule may include information such as events, for example a Lecture (Fig. 2, 25); 
days, or date (Fig. 2, 22); times (Fig. 2, 23). In addition, related information pertaining 
to the event such as location, names of people associated with the event, etc., can also be 
captured. Schedule data can be laid out in multiple formats. Altemative data formats arc 
shown in Fig. 3, wherc a mock schedule for a university student is depicted in table 
format; and Rg. 4, where a mock schedule for a businessperson is depicted. The naturc 
and content of scheduling data can vary widely depending on the individual. 

Once a schedule has been created, schedule data serve as a reference against 
which Information regarding computer usage can be checked. As shown at act 12 in Fig. 
1, as a user operates a computer, for example to access, modify, delete, or save files, 
information regarding current computer usage is accessed. This can be done in any of 
numerous ways. For exan5)le, current computer usage data can be derived by querying 
the date and time of operation. This information can reside in the computer's internal 
clock or operating system. 

As discussed, an example of information that may be accessed through the 
computer's intemal clock and compared against schedule data is tiie date and time of 
computer usage. An example of this process is depicted in Fig. 5, where a new file, 
"Acquisition Meeting Notes," (Fig. 5, 51) is being saved. The event of "Saving" ttie 
document triggers the system to access tiie computer's intemal clock to identify current 
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date and time. It should be noted that the event of accessing a computer's intemal clock 
is not dependent on employing the "Save" function, or any other function in particular. 
Accessing of the intemal clock could be repeated frequently according to a pre-set 
interval, e.g., every two minutes, or triggered by a number of user events, such as 
opening a new file, closing a file, modifying a file, etc. Sample data accessed from the 
conq>uter regarding usage, in this case, date and time regarding current usage, is depicted 
in Fig 5 at 52. For clarity, these data have been labeled Dosage and Tusage, rcspectively, 
where Dupage = September, 1 1, 2000; and Tosj^e = 9:30 (miHtary time). Accessible data 
about current usage is not limited to the date and time. 

Information about current computer usage is then cowpax&d (in act 13) to data 
captured in the schedule (Fig. 1). An illustrative example of this comparison is given in 
Fig, 6, where accessed data about usage (Fig. 6, 61), is compared against sample 
schedule data (Fig. 6, 62). For clarity, schedule date and time have been labeled, D^ch 
and Tsch, respectively, T^ch has two components, Tschi and Tsch2, to capture event start 
time and end time (Fig. 6, 63 and Fig. 6, 64). Much more data may reside in the 
schedule, for example location, participants, ete., as shown in Fig, 6, 65. 

The process of comparing con5)uter usage data to schedule data may take many 
forms. Many different comparison means, or matching algorithms, can be employed to 
achieve an effective comparison. As one example of a matching algorithm, Dupage and 
Tus^e can be compared to D^ch and Tsch. One illustrative Boolean expression for this 
sample algorithm is: 

If = Dsch , and T^e \i Tschi, and Tu^age [ Tsch2, then Match = "Yes" 
Else, Match = "No" 

This would identify a match if the current date matched the schedule data, and the 
current time was within the time boundaries of an event stipulated in the schedule. As 
discussed, matching algorithms can take many forms. An example of an alternative 
algorithm is one where a modified Tusage, for example, Tusage + 10 minutes, is coin)ared 
to the schedule. This algorithm could take into account discrepancies between computer 
usage and the start time of events, potentially improving matching accuracy. Other more 
conaplex algorithms can be employed to improve matching accuracy under different 
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usage conditions. 

An overview of this process is illustrated in Fig. 7. Date of current computer 
usage (Fig. 7, 71) is compared to the date of an event in the schedule (Fig. 7, 72). In 
addition, the time of current computer usage (Fig. 7, 73) is conq)ared to the times of an 
event in the schedule (Fig. 7, 74). Because the dates are equivalent, and the time of 
current usage is within the bounds of ttie times associated with an event in the schedule, 
a match is found C*Matched: YES"), (Fig. 7, 75). 

Finding a successful match results in attributes from the matched event in the 
schedule, e.g., activity, date, time, location, participants, etc, being associated with flie 
current file in act 15 (Fig. 1). This association can be executed automatically by the 
software, or by querying the user and asking for confirmation. This association can be 
stored wifliin the scheduling program itself, or through other means, for example, storing 
attributes with files in a database. An example of this association is given in Fig. 8, 
where a file has been successfully associated with schedule attributes in a database 
stmcture. 

If a successful match is found, additional acts, such as providing the user the 
opportunity to add or customize additional attributes to be associated with the file (act 16 
in Fig. 1), can be incorporated into the process. Many user-definable features, such as 
customizing the degree to which file association is automated, can also be incorporated 
into the process. A further option could enable the user to cancel the association process 
altogether. 

Fig. 15 illustrates a user interface for capturing and managing the schedule data 
resulting from a successful match. In this illustrative exan5>le, the user interface is 
triggered by the "Save" or "Save As" function. In addition to standard features 
associated with saving files (file name— 151, folder location— 152, file type— 153, etc.), 
schedule data has been associated with the file, 154. In this example. Meeting Name — 
155, Meeting Location— 156, Meeting Participants— 157, Participant Contact— 158, 
have been accessed from schedule data as the result of a positive match. As shown, the 
user interface can have additional fields, where the user can customize the interface — 
159, and enter additional information to be associated with the file, 160. As discussed, 
the user could also have the option not to associate any schedule data with the file 
(faciUtated in this example with the "Clear AH" function— 161), or to hide the schedule 
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data all together (facilitated in this example with 162), 

Fig, 16 illustrates one embodiment of the user interface when the user chooses to 
hide attribute data (163 is not checked). The user interface associated with attributing 
schedule data to a file is of course not limited to the "Save" or "Save As" functions, and 
additional methods for accessing and editing these data, such as a separate "File 
Attribute" menu, function, or tab, could be provided for the described in^lementation. 

In the event of a negative match, (following the previous example): 

then Match = "Yes" 

Else, Match = "No" 

the user can be queried (in act 17 in Fig, 1) directly for attributes to save or 
associate with the file, and the user can define attributes (act 18). An example of this 
process is given in Fig. 9, where data about the current file (Fig, 9, 91) do not match data 
associated with events in the schedule (Fig. 9, 92). In this exan5>le, the user is prompted 
to associate additional attributes to the file, (Fig. 9, 93), In this exanq>le, the user 
chooses to define and enter a new attribute. Fig 9, 94. These data arc then associated 
with the file. It is understood ttiat the user may choose not to associate any attributes 
with a file, whether the result of a match is negative or positive, and that it is desirable 
that the user have some degree of flexibility in customizing the matching and file 
association process. 

The final act in tiie process relates to the retrieval of data, Fig. 1,19. In tiie 
preceding acts, schedule attributes have been associated with files. The user is now 
capable of searching and identifying files with these attributes by employing a search 
tool (e.g., any common search tool). An illustrative example of the process and user 
interface for such a query is given in Fig, 10. In this example, a search window, "Find 
File" enables the user to search files by attributes (Fig. 10, 101), The data to be searched 
for is tiie name, "Jack Welsh" (Fig, 10, 102). The search functionality queries tiie 
database of files and associated attributes and returns die full results (Fig. 10, 103). 

A second illustrative example of ttie configurable software system is shown in 
Fig. 1 1. To begin, in act 251, a user inputs a schedule into flie system by using a user 
interface. A smaplQ user interface is given in Fig. 2. As discussed previously, a user 
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interface for entering a schedule typically includes information such as events, for 
example a Lecture (Fig, 2, 25); days, or date (Fig. 2, 22); times (Fig. 2, 23). In addition, 
related information pertaining to the event such as location, and names of people 
associated with the event, can also be captured (Fig. 2, 21). Schedule data can be laid 
out in multiple formats, altemative data formats are shown in Fig. 3, where a mock 
schedule for a university student is depicted in table format; and Fig. 4, where a mock 
schedule for a businessperson is depicted. The nature and content of scheduling data can 
vary widely depending on the individual. 

Once a schedule has been created, a folder structure corresponding to said 
schedule is generated in act 252. An example of such a folder structure is given in Fig. 
12. This folder stmcture corresponds to data shown in Fig. 3, where activities, *Thysics" 
and "Spanish," (Fig. 3, 31), have been captured as file folders under the folder "Classes'' 
261 in Fig. 12. 

Once a schedule and folder structure have been created, data associated with the 
schedule serve as a reference against which information regarding computer usage can be 
checked. As shown in act 253, as a user operates a computer, for txaxaplc to access, 
modify, delete, or save files, inforaiation regarding current conq)uter usage is accessed. 
This can be done in any of numerous ways as discussed above, including by querying the 
date and time of operation, which can reside in the computer's internal clock or operating 
system. As discussed previously. Fig. 5 illustrates this process. 

Information about current conq)uter usage is then conq)ared (in act 254) to data 
captured in the schedule. The previously described matching process, algorithms and 
illustrations in Figs 6 and 7, are also applicable for this embodiment of the invention. 

Finding a successful match results in the current file being saved (in act 256) in 
the folder associated with the matched schedule data, and attributes associated with the 
matched schedule data being associated with the current file. This association can be 
executed automatically by the software, or by querying the user and asking for 
confirmation. This association can be stored within the scheduling program itself, or 
through other means, for example, storing attributes with files in a database. An example 
of this saving and association is given in Fig. 13, where a file "File_Name.doc" (Fig. 27, 
271) has been successfully saved in a folder, "Heinz Acquisition Meeting" (Fig. 27, 272) 
and associated with schedule attributes in a database stracture (Fig. 27, 273). 



548897.1 



-7- 



If a successful match is found, additional acts, such as providing the user the 
opportunity to add or customize additional attributes to be associated with the file, could 
be incorporated into the process. Many user-definable features, such as customizing the 
degree to which file association is autonoated, could also be incorporated into the 
process. A fiirther option could enable the user to cancel the association and filing 
process altogether. 

In the event of a negative match, the user can be queried (act 257) directly for the 
target folder or save destination. An exan5)le of this process is given in Fig. 14, where 
data about the current file (Fig, 28, 281) do not match data associated with events in the 
schedule (Fig. 28, 282). In this example, the user is prompted (in act 258) to associate 
additional attributes to the file. In this example, the user chooses to save the file in the 
Miscellaneous Folder 284, a subfolder of the Activities folder. Because there is no 
schedule data associated with this folder, no attributes are associated with the file by the 
system. It is understood that the user may have options with the system to add or 
customize attributes according to his or her preferences. 

The final act in the process relates to the retrieval of data in act 259. In the 
preceding acts, folders and schedule attributes have been associated with files. The user 
is now capable of searching and identifying files with these attributes by employing a 
search tool. Again, an illustrative example of the process and user interface for such a 
query is given in Fig, 10. In this exeanple, a search window, "Find File" enables the user 
to search files by attributes (Fig, 10, 101). The data to be searched for is the name, "Jack 
Welsh" (Fig, 10, 102). The search functionality queries the database of files and 
associated attributes and retums the full results. 

Having described several embodiments of the invention in detail, various 
modifications and improvements will readily occur to those skilled in the art. Such 
modifications and improvements are intended to be within the spirit and scope of the 
invention. Accordingly, the foregoing description is by way of example only, and is not 
intended as limiting. The invention is limited only as defined by the following claims 
and equivalents thereto. 
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